Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-011.txt

Text File | 1992-11-18 | 54.9 KB | 1,544 lines | [TEXT/MPS ]

C.S.M.P. Digest             Mon, 09 Mar 92       Volume 1 : Issue 11

Today's Topics:

     Serial Access
    Summary on NuBus transfers
    Casting Perl before Macintoshes
    Summary: THINK C 5 oop method dispatcher address error
    pbmplus (was: Need Info on PICT file format)
    We fixed this
     Flashing the edittext cursor
     PKZIP summary and questions... (C source available)
    ResEdit and the data fork
    Blinking box on my screen
    Writing a PICT from a offscreen grafport
    Struct DInfo for ROOT Directory??
    TEXT/styl resources -- HELP
    Buggy Think C debugger?
    Assemblers?
    How to get address of (not pointer to) member function
    How to hang up on a User


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Chuck Shotton)
Subject:  Serial Access
Date: 22 Jan 92 21:15:25 GMT
Organization: OAC, U of Texas Health Science Center

In article <[e-mail]>, [e-mail] (Byron Han) writes:
>
[Original Question]
> >
> Do NOT call _RAMSDOpen except for compatibility with 64K ROM machines.
> Call _OpenDriver on the appropriate driver names.
>
> 1) check to see if ARA port arbitration is installed.  if yes, go to step 4

How do you do step 1? (Is it even worth doing when System 6 is present?)

> 2) check to see if the driver is open (use _CRMIsDriverOpen)
> 3) if yes, port is in use
> 4) call _OpenDriver
> 5) check error code
>
> you should look up what serial driver-like objects there are in the system
> using the code in the back of Inside Macintosh Communications Toolbox

Short of hard-coding tool names, there really isn't any way to determine what
the transport layer of a tool is, so how do you propose that one check for a
"serial driver-like" object? I could be overlooking something, but I seem
to only be able to get info like the number of channels, reliability, etc.
from a tool.

Chuck Shotton



---------------------------

From: [e-mail] (Todd Green)
Subject: Summary on NuBus transfers
Date: 23 Jan 92 19:32:52 GMT
Organization: Indiana University


I recently asked about maximizing NuBus transfer speeds from a
software standpoint.  Unfortunately there seems to be little that you
can do.  Here are the following messages that I received.  I've
stripped the authors' names as I personally don't feel it's correct to
post e-mail without the author's permission and I'm (frankly) to lazy
to write each author and ask.  In the future I'll try to remember to
ask if I can post.  Finally, a standard disclaimer that I'm not
responsible for any information that is incorrect.

Well enjoy,
Todd
- -------start 1----------------
  NuBus is a synchronous bus, so when the Mac CPU goes to write
on the NuBus, it must synch itself with the 10MHz clock.  Secondly,
no Mac today (even the Quadras) have the ability to perform block
transfers between the CPU and NuBus (i.e. the CPU side doesn't have
the necessary logic).  Therefore, NuBus block transfers don't do you
any good when you are talking about programming the CPU.  The best
you can do on a IIci is about 5MB/s through the Nubus using the CPU.
On the Quadras, they've added a write buffer between the CPU and the
NuBus, which increases the rate to about 8MB/s.

  Block transfers can only (at the moment) occur between two NuBus
cards (such as the 8/24GC and another video board).  In the original
NuBus, a block transfer occurs when a NuBus master asserts signals
indicating it's going to send up to 16 longwords in a continuous
stream (one per clock) to a slave board.  There is an initial
assertion signal, and a subsequent acknowledge => 18 clocks total for
the transaction, 2 for overhead, which works out to a max of about
35 MB/s between boards on the 10MHz clock.
  In NuBus 90, the clock rate can be doubled, and blocks can be up to
256 longwords.  This improves the overall bandwidth to very close to
80 MB/s.

  If you want to get into the technical details, you can ftp the NuBus
90 standard documents [IEEEP1196R] (which describe block transfers)
from ftp.apple.com in the pub/standards directory.  While you're at
it, you might also want to get the P1394 standards to see what Apple
will be doing with serial connections on their machines in the future.
- --------end 1 ----------------
- --------start 2---------------
NuBus block transfers are not supported by all cards, but for those
that support it; write as much as possible in a run. (Only a long
on 68k machines, a cache line on 68040. I don't think there's a
way for applications to actually initiate bus block transfers itself;
that's something that hardware does.)

You can never update an entire color screen during one refresh cycle
over NuBus :-(
- --------end 2 ----------------
- --------start 3 --------------
NuBus transfers information by passing an address, then data across a
common set of 32 bus lines. "Block transfer" passes a single address to
a the destination or source of the transfer, then passes sequential data
transactions. Macs, unfortunately, do not support motherboard block-mode
transfers, so it is only of use between NuBus cards, such as the 8*24 and
8*24GC which both support block mode slave and master transactions,
respectively.


A full description of NuBus, and its transactions appear in the Apple
Publication "Designing Cards and Drivers for the Macintosh Family"
- -------end 3 -----------------
- -------start 4 ---------------
The simple answer is to buy a card that goes fast and use it in a system
that drives it fast, there's almost nothing you can do in software ...

There are a number of cards that do 2 (Supermac's new ones ) or 3 (RasterOps)
cycle NuBus cycles (2 is the least possible so the fastest possible NuBus
cycle is 200nS or 5M writes/sec).

Next there are NO macs out there that generate NuBus block transfers or NuBus90
block transfers (the Quadras have a NuBus90 bus but don't actually support any
of the transfers). There are 3rd party cards that support block transfer, this
is used almost entirely for video card to card. Most video cards from the major
3rd party vendors support block transfer as a slave (not NuBus90).

Older Macs took a LONG time to get onto and off of the bus so they are even
slower too, as a rule even on the faster systems it takes on average 1/2
NuBus clock to get access to the bus, if there is other traffic on it it
may take much longer (arbitration takes 2 clocks min).

The one bright spot on the picture are the Quadras, they pipeline NuBus writes
(ie the bus interface snarfs them from the CPU right away and tells it that
it's done even though the data has not been written yet - the only bad side
effect of this is that if you write to non-existant memory location then
bus errors are broken), this means that some of the access delay can be avoided,
in fact if you use the ('040 only) mov16 instruction you can get 4 back to
back 2-cycle writes (with a fast card), mov16 requires both the source and
destination be 16-byte aligned, and in 16-byte chunks.

In short there's not much you can do other than write the tightest, fastest
code you possibly can in the lowest pixel depth you can get away with - and
remember it will run faster on some cpus than others ...
- --------end of last-----------
--
Internet: [e-mail]
NeXTMail: [e-mail]
BitNet:   [e-mail]



---------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject: Casting Perl before Macintoshes
Date: 24 Jan 92 04:08:55 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich


A port of Perl to the Apple Macintosh is available by anonymous ftp to
rascal.ics.utexas.edu, file ~ftp/mac/programming/Perl_402_MPW_CPT_bin

The file is 1.1M and must be transferred in BINARY mode. Please be considerate
to RASCAL's users during CDT working hours. (And, no, there is no way to get
it by email).

For European users, the file should soon appear on lth.se.

To make optimal use of all the features of this port, you should have
MPW, ToolServer, and 5M of memory. There is also a standalone version
included, but it's currently of very limited usefulness.

This package contains all of the sources for compilation with MPW C 3.2

Matthias

- ---
Matthias Neeracher                                   [e-mail]
       IIS, ETHZ, and CH bear no responsibility for my actions.



---------------------------

From: [e-mail] (Pete Gontier)
Subject: Summary: THINK C 5 oop method dispatcher address error
Date: 17 Jan 92 02:04:14 GMT

Recently, I wrote:

> My app started getting an address error. [...]
> I traced it down to a method call. Inside the method I put a Debugger, thinking
> I could trace down my bug. Nope. Crash happens *as a result of the method
> call*. The thread of execution never reaches the Debugger statement, which
> is of course the first statement in the problem method.

> [...]

> The weirdest thing is that this crash only occurs when the THINK C debugger
> is overseeing things. If I turn it off, I have no problems. If I could
> reproduce the crash with MacsBug only, I'd have traced this down already.

Despite the suggestions of several well-intentioned and articulate people,
this turned out to be the simplest fix of them all. I rebuilt everything.

Someone suggested it was possible that in an OOP context THINK C 5 can get
confused about headers and definitions and that sort of thing. Since this is
my second OOP project (the first wasn't even serious), I tend to move things
around an awful lot. So if it were possible for the compiler's idea of what's
where to get confused, I wouldn't be surprised if I created the conditions.

I would like to think that I don't ever try to solve problems with voodoo
like this, and it's a little disturbing to do so. I thought I was a
professional! :-)

Most of the suggestions took the form of "Probably the memory manager is
moving an object when you don't expect it to -- objects *are* handles, you
know." Well, yes, I do know, grumble grumble. Here's the method call:

   void oApplication::Run(void) {
      this->eLoop->Loop( );
   }

As you can see, this is pretty simple stuff. I suppose there could be
something wrong with the oApplication object, but I can't imagine the
thread of execution would ever arrive at oApplication::Run if it were.

Nevertheless, the advice is useful. I can construct any number of situations
in which a moved handle results in a bad method call.

Anyway, tanx for all the help, folx.
 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



---------------------------

From: [e-mail] (Larry Rosenstein)
Subject: pbmplus (was: Need Info on PICT file format)
Date: 24 Jan 92 01:32:13 GMT
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (George Phillips) writes:
>
>As usual, the PBM+ image utilities have both PICT to PPM and PPM to PICT
>converters.  Your question reminded me that I have a newer version
>of the PICT to PPM converter to post.

I have been playing around with porting the pbmplus utilities to the Mac
under MPW.  The current status is that I have a set of files that you can
use to do the port, and I've sent them to a few people to try out.  I've
only gotten one response, which seemed to be positive, so I thought I would
mention it here.

To use this, you need MPW and MPW C version 3.2 (it may be possible to get
it working with 3.1, but you will have to change the compilation flags).
You also need to obtain the pbmplus sources yourself, from one of the
archive sites.  You can optionally get the JPEG conversion sources, which
are available separately.

The porting kit is on ftp.apple.com, in /pub/lsr.  It consists of the files
you need to add to make it possible to build the tools.  Specifically, it
consists of a couple of scripts to convert the UNIX-style makefiles to
MPW-style, and a couple of header files to substitute for UNIX-related ones.

It takes about 2 hours to build everything on a Mac II.  (You can cut this
down by limiting what you build.)  The resulting tools can be piped together
and will run in the background under MPW.

If you do try this out, please send me reports of problems, comments, etc.
I already know that a couple of the files will give you compiler errors, but
these are easily fixable.  (My philosophy has been to avoid changing the
original sources, but to work around incompatibilities.)


--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)



---------------------------

From: [e-mail] (ranger::harris)
Subject: We fixed this
Date: 24 Jan 92 05:00:40 GMT
Organization: Digital Equipment Corporation


    Re: "[e-mail]"
        -< FSOpen problem with Pathworks/Appleshare >-

>    Now for the interesting part... If the pathname is fed to MSWord, (via
>    use of the Hypercard "open <file> with <app>")it will open the file.
>    After Word has opened the file once, the FSOpen *works*!!!!!! Can
>    someone shed some light on why this is the case, and how we can open
>    the file directly?
>
>    We're using Pathworks 1.0, Think Pascal 4.0, System 6.0.5 & 7 on
>    IIcx's.

    I suggest that you contact your Digital support and request the latest
    ECO against the file server, or wait for V1.1 to begin shipping (which
    "if you know what doesn't freeze over", should start happening later this
    month :-)

    The problem is that when you tried to open the file the first time with
    the full pathname, the file had never been seen before by the file
    server.  When you used MS-Word, MS-Word mostly actually performed an
    enumeration of the directory causing the file server to do a wildcard
    lookup of the huge directory and see the new file.  Upon seeing the new
    file, the file server cataloged it and you could open it with the full
    pathname after that.

    This was reported to engineering several months ago and fixed in an ECO
    available from Digital Customer Serivce Centers around the world.  If
    you try the latest ECO and it doesn't work, then contact your Digital
    Customer Support Center and have them QAR this problem to PATHWORKS for
    Macintosh engineering.

                        Bob Harris
                        Digital Equipment Corporation



---------------------------

From: [e-mail] (Greg L. Anderson)
Subject:  Flashing the edittext cursor
Date: 24 Jan 92 19:42:33 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Mike Smithwick) writes:
>Is there some mysterious global that simply points to the currently active
>item?? (oh please, oh please, oh please.........)

Yes, ((DialogRecord*)dlog)->textH.  Of  course, this value probably
won't be valid if your dialog doesn't have any editText items in it (:>),
so user-discression is advised.

Also, I've noticed that this value doesn't seem to be valid until
some dialog manager calls have been made (GetDItem does the trick
for me).

--
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Developer Tools Engineering    O O  is  ideal  O O
[e-mail]       Apple Developer Suite           O     shape     O
=====================   ===========================   =====================



---------------------------

From: [e-mail] (Bill Johnston)
Subject:  PKZIP summary and questions... (C source available)
Date: 24 Jan 92 19:44:00 GMT
Organization: University of Delaware/Department of Mechanical Engineering

In article <[e-mail]>, [e-mail] (William Johnston) writes...

>"ZIP" describes a certain set of related file compression schemes.

>Public ZIP from the INFO-ZIP project has been ported to
>PC and Unix and is available in source form for porting to the Mac,
>should anyone have the inclination to do so.

I have gotten a few requests for the source code, which was originally
posted to one of the USENET *.sources groups.  It's been un-"tar.Z"ed,
run through a newlines converter, and set up with creator code for
Think C.  I'm willing to e-mail a copy of the source to anyone who
is interested in playing with the code, or considering porting ZIP
to the Macintosh, or just interested in the INFO-ZIP project.

Background:

For those who are interested:  "ZIP" format refers to a set of
efficient file compression algorithms (roughly similar to Compact Pro
in speed and percent saved).  The archive format has been placed
in the public domain, and there are both commercial and public
implementations available on other platforms (Unix and MS-DOS).

The INFO-ZIP project recently released a freeware version of ZIP
with source code in C.  It has been ported for many variants of
Unix and unix-like operating systems.  A Macintosh version would
make for a very significant contribution to the Mac programming
community, particularly for those who have an interest in cross-
platform development and data sharing -- which are certain to become
increasingly important as Mac OS, Windows, and Apple-IBM joint
efforts make the slow but inevitable move toward open standards.

Disclaimer:  I have no connection with the INFO-ZIP project other
than having a basic interest in platform-independent development
issues.  The list of contributors to public ZIP is very long;
I'll send the whole package in ".cpt.hqx" format to anyone
who is interested.

-- Bill ([e-mail])



---------------------------

From: [e-mail] (David Elliott)
Subject: ResEdit and the data fork
Date: 3 Feb 92 04:54:09 GMT
Organization: Sony Microsystems Corp, San Jose, CA

I realize that ResEdit is for resources, but wouldn't it be nice if
it could also edit the data fork?  Even with just the standard Hex
template, it would be better than trying to find some damned program
that would let me edit the binary data.



- -------------------------

From: [e-mail] (Jess M Holle)
Subject:  ResEdit and the data fork
Date: 3 Feb 92 23:42:59 GMT
Organization: Purdue University Engineering Computer Network

I strongly agree with the previous poster's request for a hex editor for
the data fork of Mac files. I presently have no tool to edit the data
fork. Does anyone know of a free/shareware data fork editor that is System
7.1 (with Tuneup) compatible?

Jess Holle



- -------------------------

From: [e-mail]
Subject:  ResEdit and the data fork
Date: 5 Feb 92 12:45:39 -0800
Organization: BC Systems Corporation

In article <[e-mail]>, [e-mail] (Jess M Holle) writes:
> I strongly agree with the previous poster's request for a hex editor for
> the data fork of Mac files. I presently have no tool to edit the data
> fork. Does anyone know of a free/shareware data fork editor that is System
> 7.1 (with Tuneup) compatible?

I use FileEdit.  It comes with MacTools Deluxe 1.2.  I know it's not free,
actually I beleive MacSnoop 1.4.4 is exaclty the program you're looking for.  I
recently saw it on an anonymous FTP site (either Sumex [36.44.0.6],
Rascal.ics.utexas.edu [128.83.138.20] or Mac.archive.umich.edu
[141.211.164.153]). You could try these sites and let me know if it's there and
if that's what you want.

--

[e-mail]
British Columbia, Canada




- -------------------------

From: [e-mail] (Thad Humphries)
Subject:  ResEdit and the data fork
Date: 7 Feb 92 00:50:55 GMT


 --> From: [e-mail]
 --> Newsgroups: comp.sys.mac.programmer
 --> Organization: BC Systems Corporation
 -->
 --> In article <[e-mail]>,
 --> [e-mail] (Jess M Holle) writes:
 --> > I strongly agree with the previous poster's request for a hex editor
 --> for
 --> > the data fork of Mac files. I presently have no tool to edit the data
 --> > fork. Does anyone know of a free/shareware data fork editor that is
 --> System
 --> > 7.1 (with Tuneup) compatible?
 -->
 --> I use FileEdit.  It comes with MacTools Deluxe 1.2.

My grip with FileEdit is that it writes a full 512 byte sector even when you just want to write 30 or so bytes.  Try using it to set the data fork of MS Word 4.0 to zero after some office jerk registered the VP's copy to "Yo Mama" or some such trash.  You get a registered to splash screen as long as the page!  For mucking with data forks, Fedit is the best.  Too bad nothing came of it after the author went commerical...

 * Origin: Quis custodiet ipsos custodes? (1:109/70.950)



---------------------------

From: [e-mail] (David Dantowitz)
Subject: Blinking box on my screen
Date: 4 Feb 92 19:57:26 GMT
Organization: UCLA Computer Science Department


I have an interesting problem: occasionally I get a blinking
box with a hole in it, in the middle of my screen.  It looks like
this:

                               *****************
                               ********    *****
                               *****************


What am I doing in my app?  I increase the stack to 56k:
SetApplLimit(GetApplLimit()-32*1024)

Then I do lots of interesting stuff and eventually use the SCSIManager
to write data to a tape unit (an Exabyte).

Any clues?  I'm using a IIci, System 7.0.1 (NO tune up yet) and
Think C 5.0.1.

Hey, one more question... If I mark the stack with a specific
pattern just after the call to SetApplLimit above, and THEN I
check the stack's contents, would this be a good way to determine
how much stack I'm using?  Also, can the Mac use UNUSED portions
of the stack (between A7 and the ApplLimit) for random storage?
[I'm getting some strange data written to the UNUSED portions
of the stack, and I'm curious if my APP is misbehaving or if
the Mac OS can write to that stack space when it is not used.]

Also, (a FAQ) how does one catch memory leaks with the Mac's
non-protected memory?

Thanks.
--
David Dantowitz
[e-mail]

Singing Barbershop when I'm not computing...



- -------------------------

Organization: Johannes Kepler University Linz - Computing Center
Date: Wednesday, 5 Feb 1992 08:55:30 CET
From: Norbert Mueller <[e-mail]>
Subject:  Blinking box on my screen

I recently had the blinking box problem, I could get rid of it by replacing
the disk driver of my newly acquired Liberty (Conner) 120MB portable disk
with a different brand. I am not 100% sure it was the drivers fault but the
problem has not occured any more since removing that Apollyonics SCSI Director.

Norbert Mueller



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Blinking box on my screen
Date: 6 Feb 92 23:01:37 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (David Dantowitz) writes:
> I have an interesting problem: occasionally I get a blinking
> box with a hole in it, in the middle of my screen.  It looks like
> this:
>
>                                *****************
>                                ********    *****
>                                *****************
>
>
> What am I doing in my app?  I increase the stack to 56k:
> SetApplLimit(GetApplLimit()-32*1024)

> Then I do lots of interesting stuff and eventually use the SCSIManager
> to write data to a tape unit (an Exabyte).

Maybe it's something inside the Exabyte driver used for testing
(blitting bytes on the screen during debugging, and the code
is still there)?

> Hey, one more question... If I mark the stack with a specific
> pattern just after the call to SetApplLimit above, and THEN I
> check the stack's contents, would this be a good way to determine
> how much stack I'm using?  Also, can the Mac use UNUSED portions
> of the stack (between A7 and the ApplLimit) for random storage?
> [I'm getting some strange data written to the UNUSED portions
> of the stack, and I'm curious if my APP is misbehaving or if
> the Mac OS can write to that stack space when it is not used.]

I think that you always have problems finding out the exact
size of the stack, it changes all the time, all you could do
is to take snapshots at a common place in the WaitNextEvent loop,
and possibly adjust the stack size dynamically. Or then keep
a log of stack space use, and depending on the empirical data
allocate more stack size in the beginning of the program.

There are applications that create temporary stacks for internal
use, but I don't think they should mess around with the real
application stack.


> Also, (a FAQ) how does one catch memory leaks with the Mac's
> non-protected memory?

With patience... Actually I think the elimination method is the
fastest way to shake out the sucker code. Also check out the
Leak dcmds on the developer CD (and I think those are on ftp.apple.com
as well, but I'm not 100% sure).

Sade 1.4 and Steve Jasik debuggers have an option to memory protect
code with the MMU chip, and the debuggers might inform when the memory
changes (for instance protecting the ApplLimit lmg).


Kent Sandvik



- -------------------------

From: [e-mail] (Ming-Tsung Darda Chang)
Subject:  Avoid using Multi-Finder!!
Date: 6 Feb 92 06:03:34 GMT
Organization: University of Minnesota, Minneapolis, CSci dept.

In article <[e-mail]> [e-mail] (Doug McNaught) writes:
>In article <[e-mail]> [e-mail] (Ming-Tsung Darda Chang) writes:
>>Hi, Folks:
>>
>>I really need some helps or any hint to avoid using Multi-Finder when running
>>my program!!  I have been reading through the Tech. notes,
>>Inside Macintosh I-VI, but still can not help me come up with any idea.
>>I do hope any expert there can give me any kind of help to make my program work
>>on Multi-Finder without using Multi-Finder!!
>
> I'm not sure exactly what you mean. If you want to refuse to run under MF,
>there is no 'official' way to know whether MF is active or not. Otherwise, I
>can't puzzle out your prose--could you clarify?
>doug
What I intend to do is to write a login program which will force the users to
enter their usernames and passwords.  You will see the problem if my program
runs under Multi-Finder!

I used WaitNextEvent to implement it, but still failed to do so!  I will click
the outside of the login program to get access to the computers without
entering the usernames and passwords.  That makes the login program useless!

I do appreciate if you have any idea!

Thanks!

Darda
--
========================================================================
= Mr. Ming-Tsung Darda Chang                                           =
=----------------------------------------------------------------------=
= Computer Science Department              Internet: [e-mail] =



- -------------------------

From: [e-mail] (Christopher Suley)
Subject:  Avoid using Multi-Finder!!
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Thu, 6 Feb 1992 15:58:57 GMT

In article <[e-mail]>
[e-mail] (Ming-Tsung Darda Chang) writes:
>What I intend to do is to write a login program which will force the users to
>enter their usernames and passwords.  You will see the problem if my program
>runs under Multi-Finder!
>
>I used WaitNextEvent to implement it, but still failed to do so!  I will click
>the outside of the login program to get access to the computers without
>entering the usernames and passwords.  That makes the login program useless!
>
>I do appreciate if you have any idea!
>
>Thanks!
>
>Darda

If you implement the login program using a modal dialog box, you can solve
the problem very simply.

MultiFinder does not allow an application to be switched into the background
while it is displaying a modal dialog box.

Hope this helps!
--
{}-{}-{}-{}-{}-{}-{}-{}-{}-{}
{} Christopher S. Suley    {}
{} [e-mail]   {}
{}-{}-{}-{}-{}-{}-{}-{}-{}-{}



- -------------------------

From: [e-mail] (David Dantowitz)
Subject:  Blinking box on my screen
Organization: UCLA Computer Science Department
Date: Fri, 7 Feb 92 18:44:27 GMT


Thanks for the information.

The exabyte driver is not the source of the box shape, because I wrote it
and used no graphics (just calls to the SCSI manager).

BUT, the problem has been non-existent for the past 12 hours!!

What was once easily reproducable has stopped.

An earlier posting (and mail correspondance) indicated that one other
person had seen something similar.  What we had in common was that we
were both using the Apployonics disk driver.  When replaced with
SilverLining 5.31 the problem went away (So far, anyway.)

Next week I'll give them a call (as well as trying to see if I
have a leak in my software)

Thanks for the advice

David

p.s. is it still valid to set memory location 0 to 'NIL!' to trap
invalid defs?

--
David Dantowitz
[e-mail]

Singing Barbershop when I'm not computing...



---------------------------

From: [e-mail] (A.C. Lock)
Subject: Writing a PICT from a offscreen grafport
Date: 5 Feb 92 17:03:53 GMT
Organization: UEA, Norwich, UK

I have an offscreen colour grafport, and I wish to write it out to file
in PICT format. From various sources I know I have to write 512 zeros,
OpenPicture, CopyBits the pixmap to itsself and then ClosePicture. After this
I can write the contents of the picHandle. What are the contents of the
picHandle, and how long are they ?

I dont want to use bottle necks or anything, I just want to do a simple
FSWrite which writes the entire pixmap in one go. Is this possible ?

Yours

Adam Lock



- -------------------------

From: [e-mail] (Michael Peirce)
Subject:  Writing a PICT from a offscreen grafport
Date: 7 Feb 92 01:59:25 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (A.C. Lock) writes:
> I have an offscreen colour grafport, and I wish to write it out to file
> in PICT format. From various sources I know I have to write 512 zeros,
> OpenPicture, CopyBits the pixmap to itsself and then ClosePicture. After this
> I can write the contents of the picHandle. What are the contents of the
> picHandle, and how long are they ?
>
> I dont want to use bottle necks or anything, I just want to do a simple
> FSWrite which writes the entire pixmap in one go. Is this possible ?

Simply use GetHandleSize to figure out how big the pict handle is and use
that size to write the data in the handle.  You don't have to worry
about what's inside the picHandle.  You're on the right track here.

--  Michael Peirce         --   [e-mail]
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California USA 95117
--           & Consulting  --   voice: [phone] fax: [phone]
--                         --   AppleLink: peirce & America Online: AFC Peirce



---------------------------

From: [e-mail] (Ross H Leung)
Subject: Struct DInfo for ROOT Directory??
Date: 6 Feb 92 17:19:46 GMT
Organization: State University of New York at Stony Brook

Hello,
   How do you get FINDER information about the ROOT directory itself
about the finder's window rect and view type?  I can get the window
rect (from DInfo structure) by using PBGetCatInfo for any directory
in a volume BUT NOT the ROOT directory?

Please reply to:
  RLEUNG @ ic.sunysb.edu

Ross Leung
Instructional Computing
University at Stony Brook, NY



- -------------------------

From: [e-mail] (Grobbins)
Subject:  Struct DInfo for ROOT Directory??
Date: 7 Feb 92 03:42:53 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] (Ross H Leung) writes:
>   How do you get FINDER information about the ROOT directory itself
>about the finder's window rect and view type?  I can get the window
>rect (from DInfo structure) by using PBGetCatInfo for any directory
>in a volume BUT NOT the ROOT directory?

PROGRAM GetRootRect;
USES Files;
CONST kFirstDriveMountedVRefNum = -1;
VAR
  retCode: OSErr;
  myCInfoPBRec: CInfoPBRec;
  nameStr: Str255;
BEGIN
  WITH myCInfoPBRec DO
    BEGIN
      ioCompletion := NIL;
      ioNamePtr := @nameStr;
      ioVRefNum := kFirstDriveMountedVRefNum; { boot drive }
      ioDrDirID := fsRtDirID; { root has dirID 2; see Files header file }
      ioFDirIndex := 0;
      ioFVersNum := 0; { MFS compatibility, per Tech Note 204 }
    END;
  retCode := PBGetCatInfoSync(@myCInfoPBRec); { Inside Mac IV chapter 19 }
  IF retCode <> noErr THEN WriteLn('Error: PBGetCatInfo returned ', retCode)
  ELSE WITH myCInfoPBRec.ioDrUsrWds.frRect DO
    WriteLn('root window rect: ', left, ' ', top, ':', right, ' ', bottom);
END.

I cannot think of a good reason for needing this information about the
Finder windows.  Please don't try to position icons; that is best left
to the Finder (by clearing the hasBeenInited bit of the file's Finder
flags. The bit documented in chapter 9 of Inside Mac VI.)  Remember also
that the Finder caches ruthlessly, so the values obtained from disk
may not be current.

Grobbins             [e-mail]

Usual disclaimers apply.



---------------------------

From: [e-mail] (Laurence Arthur Pittenger)
Subject: TEXT/styl resources -- HELP
Organization: Yale University, Department of Computer Science, New Haven, CT
Date: Thu, 6 Feb 1992 23:55:16 GMT

Hi.

How does one unpack the TEXT/styl resources created by ResEdit into
their corresponding data structures in memory for use by a program?
Are the structure of these resources documented anywhere?  Etc.

Thanks,
LP

--

Laurence A. Pittenger
CSNET  : [e-mail]
BITNET : pitlaua@yalevm ,  pittenger-laurence@yalecs



- -------------------------

From: [e-mail] (Laurence Arthur Pittenger)
Subject:  TEXT/styl resources -- CODE
Date: 7 Feb 92 16:17:35 GMT
Organization: Yale University, Department of Computer Science, New Haven, CT


Thanks to everyone who responded. (Ok, I know it was a simple
question, but still...)

the following is adapted from a note sent to me by Andre Srinivasan at
Pitt.  Thanks Andre!


- ------------------------------------------------------

Handle        textH, styleH;
TEHandle    textEditH;
int        resID;

//
// Set up textEdit Handle first
//

// Make sure we have some text to add
texH = GetResource('TEXT', resID);
if (textH != NULL)
{
   // Clear the current text in textEditH
   TESetSelect (0,32767, textEditH);
   TEDelete (textEditH);

   // Get the corresponding style stuff from the resource (it's ok if
   //  it's NULL)
   styleH = GetResource('styl', resID);

   // Insert it into the textEdit fields
   HLock (textH);
   TEStylInsert(*textH, SizeResource(textH), styleH, textEditH);
   HUnlock(textH);

   //Clean Up
   ReleaseResource (textH);
   ReleaseResource (styleH)
}



--

Laurence A. Pittenger
CSNET  : [e-mail]
BITNET : pitlaua@yalevm ,  pittenger-laurence@yalecs



---------------------------

Subject: Buggy Think C debugger?
From: [e-mail] (Russell Street)
Date: Fri, 7 Feb 1992 03:51:20 GMT
Organization: University of Auckland, New Zealand.

Any one else found that the Think C debugger often crashes
when it starts up and quits?  It might just be my buggy software
stomping on things it shouldn't, but it seems to happen to
me all the time :-(

It seems to crash mostly when I have saved watch points/variables
and the change the source files they are in. (It also crashes
when I hold down Shift and Option to skip these.)  I generally
try to avoid leaving variables that point to odd/invalid addresses
lying around, but the Debugger normally catches these safely anyway.

Also when I use a Classic and hold down the Command key when
the Debugger starts up it gives me a user break in the debugger.
This might be a valid and useful feature, but then why does it
NOT do it on other machines.

Once I quit my application and it crashed badly in the Debugger when
it quit. Unfortunately my boss was *watching* at the time
-- hitting the RESET button when you quit the does not inspire
confidence.  (Well MacsBugs said it was the Debugger, and my
app's windows had disappeared.)

The upgrades to from 5.0 to 5.0.1 and then 5.0.2 did not help matters.
(Though I have never had these troubles with version 4.0.x, however.)

Any pointers to what I am doing wrong appreciated...
- -----------------------------------------------------------
Russell Street                     [e-mail]
"Baldrick, I believe the phrase rhymes with 'clucking bell'."
        -- Edmund Blackadder





- -------------------------

From: [e-mail] (Matthew T. Russotto)
Subject:  Buggy Think C debugger?
Date: Fri, 07 Feb 92 15:05:54 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <[e-mail]> [e-mail] (Russell Street) writes:
>Any one else found that the Think C debugger often crashes
>when it starts up and quits?  It might just be my buggy software
>stomping on things it shouldn't, but it seems to happen to
>me all the time :-(

No, but I DO have it crash quite often if I start it up and immediately hit
Command-I (to bring up the appropriate source file).
The debugger and Think C both hang, and attempts to force quit result in a
locked up cursor.

This is with THINK C 5.0.2 on a Mac II running System 7.0.1* with Mode32 and
20MB of VM.
--
Matthew T. Russotto    [e-mail]    [e-mail]
Your superior intellect is no match for our puny weapons! -- The Simpsons
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



---------------------------

From: [e-mail] (Philip Machanick)
Subject: Assemblers?
Date: 7 Feb 92 11:51:41 GMT
Organization: Wits Univ. Computer Science Dept.

I need an assembler that will run comfortably on SEs without
hard disks. Consulair M68000 assembler seems to be about right,
except the version I bought early last year seemed old and had
a number of irritating bugs. I am aware that THINK C supports
embedded assembly language, but that's too expensive for my
budget (and probably needs a hard disk anyway).

Does anyone have a phone / fax number for Consulair? The numbers
on the disks seem to be out of date. Alternatively, information
about other lightweight assemblers would be useful. (This is for
a course on assembly language programming - no need for strong
toolbox support etc. - just a good solid assembler that doesn't
need a hard disk.)

Any other ideas on this would be appreciated.
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone [phone] fax [phone]



- -------------------------

From: [e-mail] (Jerome Jahnke)
Subject:  Assemblers?
Date: 7 Feb 92 21:21:00 GMT
Organization: Biology Learning Center

In article <[e-mail]>, [e-mail] (Philip Machanick) writes:
>
> I need an assembler that will run comfortably on SEs without
> hard disks. Consulair M68000 assembler seems to be about right,
> except the version I bought early last year seemed old and had
> a number of irritating bugs. I am aware that THINK C supports
> embedded assembly language, but that's too expensive for my
> budget (and probably needs a hard disk anyway).
>

I used to use MacAssembly, and it worked for the longest time, and
I did not know how good I had it until I bought the Consulair product
and well, I got so upset that I bought MPW. MacAssembly was a share-
ware product. I do know that the author got upset and stopped working
on it, but if you root around enough you should find it. It is a nice
Assembler and will run just fine on a floppy system.

> --
> Philip Machanick                   [e-mail]
> Department of Computer Science, University of the Witwatersrand
> 2050 Wits, South Africa
> phone [phone] fax [phone]
>
>

Jer,
- --
Jerome Jahnke
Biology Learning Center
University of Arizona
'[e-mail]' or [phone]



---------------------------

From: [e-mail] (Ben Hekster)
Subject: How to get address of (not pointer to) member function
Date: 22 Jan 92 11:31:06 GMT
Organization: University of Twente, Dept. of Computer Science

How do you get the actual address of a nonstatic member function?
Not the C++ `pointer to member function' but the straight C `pointer
to function'.  I need this to unload the code segment in which the
function resides.  For example,

    class X {
        virtual void f();    // unloads segment containing u()
        virtual void u();    // `UnLoad'able function
        };



    /*    X::f()
        Unload the code segment containing X::u()
    */
    void X::f() {

    // pointer to member function
    void (X::*pmf)() = &X::u;    // fine, but not what I need

    // pointer to function?
    void (*pf)() = (void (*)()) pmf;// anachronism

    // unload the segment
    UnloadSeg((void*) pf);        // needs the actual address
    }

That is, I can get the `pointer to member function', but all my
attempts (I've tried this in at least five different ways) either
do not compile or, like the above example, do not produce the
desired result.  In particular, in the code above, `pf' is not
the address of the function at all but something that looks like
an offset in the virtual function table.

    The problem gets worse when I try to get a pointer to one
particular of a set of overloaded functions.

    Conversion of `pointer to member function' to `pointer to
function' is an anachronism pointed out on the very last page of
the [ARM].  I can understand that "any use of the resulting pointer
is undefined", but I don't want to use it to call the function, I
just need the address.  Is there any `legal' way to do this?

    I'm using MPW CFront (v1.0, I think).

(I'm directing follow-ups to comp.lang.c++)
--
Ben `Hackster' Hekster            | sigblock(sigmask(SIGFLAME));
[e-mail]            | "Here we are now, entertain us"



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  How to get address of (not pointer to) member function
Date: 24 Jan 92 20:21:48 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ben Hekster) writes:
>
> How do you get the actual address of a nonstatic member function?
> Not the C++ `pointer to member function' but the straight C `pointer
> to function'.  I need this to unload the code segment in which the
> function resides.  For example,
>
>     class X {
>         virtual void f();    // unloads segment containing u()
>         virtual void u();    // `UnLoad'able function
>         };
>

You can't use a virtual function for UnloadSeg(). This because
the entry is really an offset to the vtable function ptr (4 byte value).

The way to fix this is to add - sigh - a dummy function in the same
segment, and use this one if you want to UnloadSeg() the particular
segment. Actually, if someone else has a better trick, please let us know.

I am working on a "MPW C++ Pitfalls" Tech Note which should address such
pesky issues. I don't know when it's released, I guess the label
RealSoonNow is a good estimate of the release date.

Kent the fake Sandvik
PS: Who forged me?



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  How to get address of (not pointer to) member function
Date: 24 Jan 92 21:28:19 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Kent Sandvik) writes:
>The way to fix this is to add - sigh - a dummy function in the same
>segment, and use this one if you want to UnloadSeg() the particular
>segment. Actually, if someone else has a better trick, please let us know.

I found that sometimes when I resegmented my program I'd forget to change
the function names in my segment unloader.  So, I wrote a little perl
script (here's your chance to try the MPW perl announced a little while
ago).

You invoke it with all your source files as arguments.  It looks for segment
directives, puts a dummy routine in each segment, and writes a complete
segment unloader source file on stdout.

#!/usr/local/bin/perl
while (<>)
{
  if (/^#pragma segment/)
  {
    chop;
    split;
    if ($_[2] ne "Main")
    {
      $seglist{$_[2]} = $_[2];
    }
  }
}

print '#pragma load "declarations.load"\n';
foreach $seg (keys(%seglist))
{
  printf "#pragma segment %s\n",$seg;
  printf "void __Seg%s(void);\n",$seg;
  printf "void __Seg%s(void){}\n",$seg;
}
print <<"EOF";
#pragma segment Main
void UnloadSegments(void)
{
  extern void _DataInit();
  extern char *strchr();
  UnloadSeg(_DataInit);
  UnloadSeg(strchr);
EOF
foreach $seg (keys(%seglist))
{
  printf "  UnloadSeg(__Seg%s);\n",$seg;
}
print "}\n";
--
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
Apparently-To: does more harm than good.



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  How to get address of (not pointer to) member function
Date: 24 Jan 92 20:21:48 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ben Hekster) writes:
>
> How do you get the actual address of a nonstatic member function?
> Not the C++ `pointer to member function' but the straight C `pointer
> to function'.  I need this to unload the code segment in which the
> function resides.  For example,
>
>     class X {
>         virtual void f();    // unloads segment containing u()
>         virtual void u();    // `UnLoad'able function
>         };
>

You can't use a virtual function for UnloadSeg(). This because
the entry is really an offset to the vtable function ptr (4 byte value).

The way to fix this is to add - sigh - a dummy function in the same
segment, and use this one if you want to UnloadSeg() the particular
segment. Actually, if someone else has a better trick, please let us know.

I am working on a "MPW C++ Pitfalls" Tech Note which should address such
pesky issues. I don't know when it's released, I guess the label
RealSoonNow is a good estimate of the release date.

Kent the fake Sandvik
PS: Who forged me?



---------------------------

From: [e-mail] (GILPIN, W.W.)
Subject: How to hang up on a User
Date: 23 Jan 92 04:12:00 GMT
Organization: Texas A&M University, Academic Computing Services

I am writing a BBS program and am at the point where I need to be able to hang
up on a user after a timeout, or deal with a lost carrier, no matter where
in the program the user is(Well, actually it only checks at the prompts, but
I'll get into that later). What I need help with is how to return from all
the procedure calls the user is in at the time to keep from overflowing that
stack. Here's how it would look:

Main-->BBS-->SubBoards-->PostMessage-->Editor-->GetLine
(sample nested function names for a user logged on and posting a message)

GetLine can detect when a user has dropped carrier or has timed out and can
hang up the phone. Now what I need to do is zip all the way back to Main and
reset the BBS.

My Idea:Use a global flag variable. (i.e. UserGone). Normally False. GetLine
sets it to true if timeout or no carrier. Each call of GetLine must have a
check for this flag upon return and then jumps to the end of the function
if it's true. Then each procedure call that could possibly include a GetLine
call must also have this check so it could make it back to the beginning.

This seems amazingly complex and Kludgy. Do any of you programming Gurus out
there have any ideas on how this can be done more simply, or will I be forced
to double up on all of my function calls?

Wes Gilpin
WWG2101@TAMZEUS
[e-mail]



- -------------------------

From: [e-mail] (| particle man |)
Subject:  How to hang up on a User
Date: 23 Jan 92 18:19:18 GMT
Organization: University of Illinois at Urbana


This may not answer your question, but why don't you just invert DTR
and make sure that your users' modems are configured properly to
handle it by shouting it at the top of your lungs in your docs?


--

    "Laugha while you cana, Monkey Boy!" -Emilio Lizardo



- -------------------------

From: [e-mail] (Nick Rothwell)
Subject:  How to hang up on a User
Date: 23 Jan 92 11:47:12 GMT
Organization: Laboratory for Foundations of Computer Science.

In article <[e-mail]> [e-mail] (GILPIN, W.W.) writes:

   GetLine can detect when a user has dropped carrier or has timed out and can
   hang up the phone. Now what I need to do is zip all the way back to Main and
   reset the BBS.

What's wrong with longjmp()?

    Nick.
--
Nick Rothwell, LFCS, Edinburgh | Performance: A-11  FANCY-SIGNATURE   [COMPARE]
             [e-mail] | Key Mode: ZONE **  MIDI-Sep-Ch: Off Split: C#4
Mentation Consultancy Services | Upper: a-34 LOUD.SIGNATURE  FX1: QuadChorus+EQ
   [e-mail] | Lower: b-11 DISCLAIMERVOIC  FX2: Vocoder/Delay



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  How to hang up on a User
Date: 24 Jan 92 15:15:38 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ac.uk> [e-mail] (Nick Rothwell) writes:

      GetLine can detect when a user has dropped carrier or has timed out
      and can hang up the phone. Now what I need to do is zip all the way
      back to Main and reset the BBS.

   What's wrong with longjmp()?

Allocated memory, opened files, started transactions, queued events,
asynchronous I/O, ... for instance.

It's usually much better to use an error return code for each function.
You _could_ use longjmp, but that'd need wrappers for all files you open,
all memory you allocate, all application-dependent data structures, ...
so you could reset/close/free all of these after the longjmp.


--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Greg L. Anderson)
Subject:  How to hang up on a User
Date: 24 Jan 92 20:54:17 GMT
Organization: Apple Computer Inc., Cupertino, CA

Some unquoted user asked:
>   What's wrong with longjmp()?

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>Allocated memory, opened files, started transactions, queued events,
>asynchronous I/O, ... for instance.
>It's usually much better to use an error return code for each function.

Yes, but that's _so_ painful; it involves way too many if statements.

>You _could_ use longjmp, but that'd need wrappers for all files you open,
>all memory you allocate, all application-dependent data structures, ...
>so you could reset/close/free all of these after the longjmp.

Now you're giving good advice.  Failure handlers are not hard to
write, and I think there has been at least one package published in
d e v e l o p  (although offhand I don't know if that's true or
not).

I have a set of setjmp/longjmp based failure routines, if anyone is
interested.  It was written for Think C, but should work in other
environments too.

--
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Developer Tools Engineering    O O  is  ideal  O O
[e-mail]       Apple Developer Suite           O     shape     O
=====================   ===========================   =====================



- -------------------------

From: [e-mail] (Patrick Logan)
Subject:  How to hang up on a User
Date: 25 Jan 92 01:21:42 GMT
Organization: Mentor Graphics Corporation


   From: [e-mail] (Greg L. Anderson)
   >You _could_ use longjmp, but that'd need wrappers for all files you open,
   >all memory you allocate, all application-dependent data structures, ...
   >so you could reset/close/free all of these after the longjmp.

   Now you're giving good advice.  Failure handlers are not hard to
   write, and I think there has been at least one package published in
   d e v e l o p  (although offhand I don't know if that's true or
   not).

   I have a set of setjmp/longjmp based failure routines, if anyone is
   interested.  It was written for Think C, but should work in other
   environments too.

I developed something similar using Aztec C a long time ago, based on
CommonLISP's CATCH, THROW, and UNWIND-PROTECT. It was trivial to
implement.

Watch out if you're using C++, though! (Obviously?)
--
Patrick Logan, [e-mail],
Voice: [phone] x2907, FAX: [phone]
Mentor Graphics Corp., Bldg. C, 8005 SW Boeckman Rd., Wilsonville, OR 97070
I can't gete the .signature virus and I can't gete the .signature



- -------------------------

From: [e-mail] (Greg L. Anderson)
Subject:  How to hang up on a User
Date: 24 Jan 92 20:54:17 GMT
Organization: Apple Computer Inc., Cupertino, CA

Some unquoted user asked:
>   What's wrong with longjmp()?

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>Allocated memory, opened files, started transactions, queued events,
>asynchronous I/O, ... for instance.
>It's usually much better to use an error return code for each function.

Yes, but that's _so_ painful; it involves way too many if statements.

>You _could_ use longjmp, but that'd need wrappers for all files you open,
>all memory you allocate, all application-dependent data structures, ...
>so you could reset/close/free all of these after the longjmp.

Now you're giving good advice.  Failure handlers are not hard to
write, and I think there has been at least one package published in
d e v e l o p  (although offhand I don't know if that's true or
not).

I have a set of setjmp/longjmp based failure routines, if anyone is
interested.  It was written for Think C, but should work in other
environments too.

--
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Developer Tools Engineering    O O  is  ideal  O O
[e-mail]       Apple Developer Suite           O     shape     O
=====================   ===========================   =====================



---------------------------

End of C.S.M.P. Digest
**********************